Session tokens that exhibit low entropy ("randomness") are often susceptible to prediction attacks. Insecure tokens can be due to inadequate pseudo-random number generator, time-based values, static values, or values based on user attributes (username or user ID). This means that an attacker would be able to guess a valid session token after monitoring the application for a short period of time and gathering the session tokens it creates. If the attacker determines a valid session token for another user, then it may be possible to view, modify, or delete arbitrary users' data without having to guess the victim's username or password. Consequently, the ability to deduce valid session tokens enables the attacker to bypass login pages and obviate the need to brute force accounts.
Additionally, static tokens can enable the attacker to target users even if the victim is not currently logged into the application. This increases the pool of victims which the attacker can target.

Session tokens should be created with a strong random number generator and gathered from a large pool of numbers. For example, an operating system's rand() function can usually be sufficient if it can produce 32-bit values that are a statistically uniform distribution. Poor session tokens are incremental, rely on the user's account ID, only use time stamps, or have other highly deterministic information. Other methods of protecting a session token's security are to always transmit them over SSL, automatically expire the token after a certain period of time, and explicitly expiring the token whenever a user logs out of the application.

If the session values exhibit strong randomness, but are chosen from a small pool of values, then the attacker has a better chance of simply guessing a valid token. A web application's session management can be improved by implementing several complementary techniques:

• Make sure that the Token values are at least 32 bits in size, especially for applications with large numbers of concurrent users and high amounts of daily page requests.
• The bit size of the source of the entropy (random values) is more important than the bit size of the actual session token. For example, an MD5 hash produces a 128 bit value. However, the MD5 hash of incremental values, a timestamp, or 8-bit random numbers are each insecure because the source of the random values can be easily predicted. Consequently, the 128 bit size does not represent an accurate measure of the session token. The minimum size of the entropy source is 32 bits, although larger pools (48 or 64 bits) may be necessary for sites with over 10,000 concurrent users per hour.
• In most cases, application-generated tokens (e.g. ASP.NET_SessionId, ASPSESSIONID, JSPSESSIONID, PHPSESSIONID) provide sufficiently large random values to prevent session prediction attacks. The application should use these session management alogorithms unless a custom session mechanism has been thoroughly reviewed and tested.
• Track user attributes associated with the session token with server-side objects to prevent user impersonation attacks. If the application does not strictly associate a user's session token with that user's profile information, then an attacker may be able to view arbitrary information by manipulating client-side values. For example, if the application sets a strong session token, but performs SQL queries based on a "UserId" cookie, then an attacker only needs to modify the "UserId" cookie to impersonate someone else. The application would be more secure if it associated the "UserId" value with the server-side session object because the attacker would not be able to modify the value.
• Expire session tokens when the user logs out of the application or after a predetermined period of inactivity. We recommend using a 20 minute timeout for a session token, although this largely depends on the type of application and the expected usage.

A valid username and password combination was discovered for the application.
Default passwords and trivial passwords expose an application to unauthorized access.
If a user chooses a very insecure password, then that user's account information can be compromised and the account can be used to attempt to compromise the application.

Enforce a strong password security policy.

1. Require that all passwords have a suitable minimum length.
2. Require that all passwords have a suitable complexity, using mixed-case alphanumeric content.
3. Require that all passwords expire periodically and have suitable rules for re-use of previously expired passwords.

Sending credentials over HTTP

Credentials or sensitive data is transmitted without encryption and a malicious user could read user's sensitive data by simply sniffing the net with a tool like Wireshark. HTTPS protocol ensures that data is sent through an encrypted channel and not readable by other people.

Reflected Cross-site Scripting (XSS) is another name for non-persistent or Type-II XSS, in which the attack doesn't load with the vulnerable web application but is instead originated by the victim loading the offending URI.

Reflected XSS attacks are the most frequent type of XSS attacks found nowadays.

When a web application is vulnerable to this type of attack, it will pass unvalidated input sent through requests to the client. Reflected attacks are delivered to the victim in various ways, such as in an e-mail message, or through some specially crafted URI. When a user is tricked into clicking on the malicious link, the injected code travels to the vulnerable web site, which reflects the attack back to the user’s browser. The browser then executes the offending code because it came from a "trusted" server.

Commonly the attacker's code is written in the Javascript language, but other scripting languages are also used, e.g., ActionScript and VBScript.

Attackers typically leverage these vulnerabilities to install key loggers, steal victim cookies, perform clipboard theft, and change the content of the page (e.g. download links).

To remediate against reflected XSS vulnerabilities, strict filtering of HTML character encodings must be adhered to. In some cases, the web application may not be filtering some character encodings. For example, it may filter out "<script>", but might not filter "%3Cscript%3E" which simply includes another encoding of tags. A nice tool for testing character encodings is OWASP's CAL9000.

Filtering of all information sent to the server via form POST/GET and URL query parameters with a particular emphasis on filtering out HTML-specific characters is advised.

Unencrypted HTTP connections create a vulnerability and expose potentially sensitive information about users. This data can include browser identity, website content, search terms, and other user-submitted information. To address these concerns, many commercial organizations have already adopted HTTPS-only policies to protect visitors to their websites and services

All networks, both external and internal, must utilize TLS or an equivalent transport layer security mechanism for all communication. By always using HTTPS, web services don not have to make a subjective judgment call about what's sensitive. This leaves less room for error, and makes deployment simpler and more consistent.

The Content Security Policy hasn't been declared properly either through the meta-tag or the header, so the browser's trust of the content received from the server can be exploited. Malicious scripts are executed by the victim's browser because the browser trusts the source of the content, even when it's not coming from where it seems to be coming from.

The Content-Security-Policy HTTP response header helps you reduce XSS risks on modern browsers by declaring what dynamic resources are allowed to load via a HTTP Header. CSP makes it possible for server administrators to reduce or eliminate the vectors by which XSS can occur by specifying the domains that the browser should consider to be valid sources of executable scripts. A CSP compatible browser will then only execute scripts loaded in source files received from those allowlisted domains, ignoring all other script (including inline scripts and event-handling HTML attributes).

HTML forms are a key component to exchanging information between a user and the server.
Browser feature of remembering what you entered in previous text form fields with the same name.
So, for example, if the field is named 'name' and you had entered several variants of your name in other fields named name, then autocompletion provides those options in a dropdown.

The password autocomplete should always be disabled, especially in sensitive applications, since an attacker, if able to access the browser cache, could easily obtain the password in cleartext (public computers are a very notable example of this attack).
You can turn it off by setting AUTOCOMPLETE to OFF:
<input autocomplete="off" name="oPassword" type="password" >

A cross-domain policy file specifies the permissions that a web client such as Java, Adobe Flash, Adobe Reader, etc. use to access data across different domains. For Silverlight, Microsoft adopted a subset of the Adobe's crossdomain.xml, and additionally created it's own cross-domain policy file: clientaccesspolicy.xml. Whenever a web client detects that a resource has to be requested from other domain, it will first look for a policy file in the target domain to determine if performing cross-domain requests, including headers, and socket-based connections are allowed. Master policy files are located at the domain's root. A client may be instructed to load a different policy file but it will always check the master policy file first to ensure that the master policy file permits the requested policy file.

There are several recomendation prio to deployment of a cross-domain policy file:

• Carefully evaluate which sites will be allowed to make cross-domain calls. Consider network topology and any authentication mechanisms that will be affected by the configuration or implementation of the cross-domain policy.
• Limit the scope of the cross-domain policy to only the desired functionality by creating subdomains or virtual directories containing shared functionality.
• Review any XSRF prevention mechanisms to see if they may be affected by allowing cross-domain data loading.

Sending sensitive data over HTTP

Credentials or sensitive data is transmitted without encryption and a malicious user could read user's sensitive data by simply sniffing the net with a tool like Wireshark. HTTPS protocol ensures that data is sent through an encrypted channel and not readable by other people.

When a web form is submitted to a server through an HTTP POST request, a web user that attempts to refresh the server response in certain user agents can cause the contents of the original HTTP POST request to be resubmitted, possibly causing undesired results, such as a duplicate web purchase.

To avoid this problem, many web developers use the PRG pattern - instead of returning a web page directly, the POST operation returns a redirection command.
Post/Redirect/Get (PRG) is a web development design pattern that prevents some duplicate form submissions, creating a more intuitive interface for user agents (users). PRG implements bookmarks and the refresh button in a predictable way that does not create duplicate form submissions.

Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack. An information leak occurs when system data or debugging information leaves the program through an output stream or logging function.

Depending upon the system configuration, this information can be dumped to a console, written to a log file, or exposed to a remote user. In some cases the error message tells the attacker precisely what sort of an attack the system will be vulnerable to.
For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system.
In the example above, the search path could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.

The HttpOnly attribute directs browsers to use cookies via the HTTP protocol only. An HttpOnly cookie is not accessible via non-HTTP methods, such as calls via JavaScript (e.g., referencing "document.cookie"), and therefore cannot be stolen easily via cross-site scripting (a pervasive attack technique).

If the HttpOnly flag (optional) is included in the HTTP response header, the cookie cannot be accessed through client side script (again if the browser supports this flag). As a result, even if a cross-site scripting (XSS) flaw exists, and a user accidentally accesses a link that exploits this flaw, the browser (primarily Internet Explorer) will not reveal the cookie to a third party.

The SameSite attribute restricts the browser from sending cookies in certain cross-site requests. This can provide protection against cross-origin information leakage and cross-site request forgery attacks. When set to "strict", the cookie will be sent with same-site requests only. When set to the default value of "lax", the cookie will be withheld on cross-site sub-requests (e.g. load images), but will be sent on any top-level navigation to a URL from an external site (e.g. following a link).

The SameSite attribute, with a value of "strict" or "lax", should be used for any session cookie (or any cookie that contains sensitive information) that may be sent in a cross-site request. Be aware that when using a value of "lax", such cookies will still be sent on cross-site requests from web forms that use the GET method. Using a value of "strict" will protect against this but may reduce usability. By considering the context in which the cookie will be used and how sensitive it's contents are, the value can be chosen accordingly. It should also be noted that the SameSite attribute does not provide complete protection against cross-site attacks and it should therefore be used in conjunction with CSRF tokens and other measures to provide good protection.

Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into loading a page that contains a malicious request. It is malicious in the sense that it inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf, like change the victim's e-mail address, home address, or password, or purchase something. CSRF attacks generally target functions that cause a state change on the server but can also be used to access sensitive data.
For most sites, browsers will automatically include with such requests any credentials associated with the site, such as the user's session cookie, basic auth credentials, IP address, Windows domain credentials, etc. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish this from a legitimate user request.
In this way, the attacker can make the victim perform actions that they didn't intend to, such as logout, purchase item, change account information, retrieve account information, or any other function provided by the vulnerable website.
Sometimes, it is possible to store the CSRF attack on the vulnerable site itself. Such vulnerabilities are called Stored CSRF flaws. This can be accomplished by simply storing an IMG or IFRAME tag in a field that accepts HTML, or by a more complex cross-site scripting attack. If the attack can store a CSRF attack in the site, the severity of the attack is amplified. In particular, the likelihood is increased because the victim is more likely to view the page containing the attack than some random page on the Internet. The likelihood is also increased because the victim is sure to be authenticated to the site already.
Synonyms: CSRF attacks are also known by a number of other names, including XSRF, "Sea Surf", Session Riding, Cross-Site Reference Forgery, Hostile Linking. Microsoft refers to this type of attack as a One-Click attack in their threat modeling process and many places in their online documentation.

Web sites have various CSRF countermeasures available:

• Requiring a secret, user-specific token in all form submissions and side-effect URLs prevents CSRF; the attacker's site cannot put the right token in its submissions
• Requiring the client to provide authentication data in the same HTTP Request used to perform any operation with security implications (money transfer, etc.)
• Limiting the lifetime of session cookies
• Ensuring that there is no clientaccesspolicy.xml file granting unintended access to Silverlight controls
• Ensuring that there is no crossdomain.xml file granting unintended access to Flash movies

An easy and effective solution is to use a CSRF filter such as OWASP's CSRFGuard. The filter intercepts responses, detects if it is a html document and inserts a token in to the forms and optionally inserts script to insert tokens in ajax functions. The filter also intercepts requests to check that the token is present.

Global variables are easily leaked in Javascript. You may consider the following javascript code used in the default, non-strict mode:

      function f(){
       Token = 1;
      }
      f();
      console.log("I can still see Token: " + Token);
      

To prevent these mistakes from happening, add 'use strict'; at the beginning of your JavaScript files. This enables a stricter mode of parsing JavaScript that prevents accidental globals. Strict mode makes several changes to normal JavaScript semantics. First, It prevents, or throws errors, when relatively "unsafe" actions are taken. Second, strict mode eliminates some JavaScript silent errors by changing them to throw errors.

The encoding hasn't been declared either through the meta-tag, the byte-order-mark or the header, so the browser will make an attempt to detect the document's encoding. This exploit only works if the document reflects user input and the browser can be tricked into encoding the page as UTF-7 instead of UTF-8. Some of the browsers actually support UTF-7.

Add X-Content-Type-Options response header to all responses:
X-Content-Type-Options: nosniff

Always declare the character encoding of all text documents (html, text, stylesheet, javascript, xml). Use the HTTP header if you can. Always use an in-document declaration too.
You can use @charset or HTTP headers to declare the encoding of your style sheet, but you only need to do so if your style sheet contains non-ASCII characters and, for some reason, you can't rely on the encoding of the HTML and the associated style sheet to be the same.
Try to avoid using the byte-order mark in UTF-8, and ensure that your HTML code is saved in Unicode normalization form C (NFC).